Various embodiments of this disclosure relate to load balancing and, more particularly, to load-balancing systems and methods configured to redistribute workloads.
In many cases, a set of workloads will need to be balanced among various virtual servers, such that the servers avoid being overloaded and thereby produce a slow return on work. A workload can be, for example, a transactional workload or a batch workload.
Transactional workloads are typically not processor intensive, and each transaction making up these workloads is usually short-running. More specifically, a transaction will usually complete in thirty microseconds to two minutes. Transactional workloads are routed by a load balancer to multiple virtual servers, with most work at a given time being routed to the virtual server with the highest free capacity among the multiple virtual servers. Transactional workloads tend to be predictable and are executed quickly. Because of this, reduced server capacity due to increased work or other factors tends to have a relatively small impact on workload completion times of transactions.
In one example, a load balancer routes a large number of transactions to a first virtual server that appears to have the highest free capacity from among the available virtual servers in a load-balancing system. After this routing, a processor-intensive workload may be assigned to the first virtual server or to a second virtual server sharing a hypervisor with the first virtual server. Either way, transaction processing on the first virtual server slows because the first virtual server now has less free capacity than it appeared to have at the time of routing the transactions. The load balancer then accounts for the change in free capacity and sends fewer future workloads to the first virtual server. The transactional workloads already routed to the first server will experience more delay than originally expected, but may still be completed by the first virtual server in a reasonable time period. Due to the large volume of transactions that are likely being processed by the load-balancing system, and further due to the short processing time for completing a single transaction in general, the percentage of transactions not meeting response time goals may remain small for the transactions already routed to the first virtual server. Thus, while a delay may occur, such delay may be reasonable.
In contrast to transactional workloads, batch workloads tend to run for a relatively long time each, e.g., from twenty minutes to several hours. Additionally, they can be unpredictable, and a single batch may suddenly become more processor intensive than it was initially expected to be. Thus, there is no specific pattern of processor consumption when dealing with batches.
In another example, batch workloads B1, B2, and B3 are routed to a virtual server. Initially, they consume little processing resources, so an additional batch workload B4 is sent to the same virtual server. Batches B1 and B4 suddenly begin to consume large processor capacity. Current feedback to the load balancer indicates that no new work should be sent to the virtual server. Unfortunately, the batches already sent to that virtual server will experience significant delays. Thus, due to their lack of predictability, batch workloads can present significant problems within a load-balancing system.